-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persistent High alert threshold #3554
Conversation
My concerns 1- If a user installs xDrip after this PR is merged and sets a persistent high alert threshold and then, installs an older version of xDrip prior to this PR, their persistent high alert will automatically use their High Value as their alert threshold. 2- If a user installs xDrip after this PR is merged and sets a persistent high alert threshold and then, loads settings they had saved before this PR, their persistent high alert will use the default value, 170 mg/dL. This first scenario is inevitable. Older versions of xDrip have no idea about a setting that did not exist then. The second scenario is indirectly caused because xDrip is incapable of importing settings. Instead, it restores settings. I can add a special marker to such releases in the release notes marking a release that the user should be careful going over in time in reverse order. |
So, why do we need this? After I eat, I may go high for a short while. But, I need to come back down shortly after. To ensure about that, I use the persistent high alert. And I set it to 7.5mmol/L (135 mg/dL). This change will allow me to set my persistent high alert with no impact on my statistics. |
If this is merged, there will be an announcement in the facebook group to highlight that if/when someone changes their high level, their persistent high alert will not be affected as it was before. If this is not adequate, in order to get this merged, we can add a listener to high level. Whenever there is a change, a log a toast will be issued informing the user that the persistent high alert has a dedicated threshold that is not affected by this change. I hope you won't ask for this. |
It seems that this change is also changing the default value of the alert from 170 to 135. I believe that for most people 170 is a better value. |
@tzachi-dar How did we come up with that decision? There is a correlation between the average blood glucose and A1C. If someone has their blood glucose at 169 most of the time, which will never hear a persistent high alert if their persistent high alert threshold is set to 170, their A1C, according to that paper, will be 7.5. So, I am curious why you say that. The definition of non-diabetic is someone whose A1C is less than 5.7 Of course, we don't just have a persistent high alert. So, it's the combination of all the alerts that help us control our diabetes. An individual may have 3 main meal a day. If after each one of those meals, the glucose stays above 169 for an hour, they will never hear a persistent high alert. The persistent high alert is not even enabled by default. |
@tzachi-dar Thanks for your comment. After seeing your comment, and thinking about it more, I see that we should keep in mind we should not give users the idea that their blood glucose is too high encouraging them to take too much insulin. This has to be done by a doctor. I never created this PR in order to change the default. My intent was to separate the two settings from each other and when I created the new setting, it needed a default and I chose the default based on what I was using myself. That is not the right way for choosing a default. I am happy to change the default. My only objective for this PR is to separate the settings. |
I have set the default of the new setting to 170. Therefore, the default threshold of the persistent high alert remains unchanged if this PR is merged. |
There are many settings on the Extra Alerts page. I can add a level of hierarchy to it. So, the page would only have the following on it: Then, if it helps getting this approved, I will add a checkbox to the Persistent High page that would be: Link to High Value |
I will use a different approach where the default behavior will be identical to what we have now in a new PR that I will open later. |
After this change, a user can set a persistent high alert threshold different than the High Value, used for statistics.
Since xDrip persistent high alert has been there for years, we must be careful not to cause any unintended change to its behavior.
If an existing user updates to a release after this PR is merged, their High Value is automatically used as their new Persistent High alert threshold.
This is what the persistent high alert menu looks after this PR:
This is the log that is shown after an update:
There are two concerns I have about this PR explained in the next post.